Revision 572: Signals

Transcript

[0:00] Also da gibt es auf YouTube eine Sache, die mir richtig gut gefällt bei den Signals und das ist das Automatic Dependency Tracking.
Statt dem Dependency Array wissen die selber, wo die Änderungen herkommen.
Und das finde ich schon einen schönen Selling Point von Signals.
Und wenn extrem kompetente Leute mit einem extrem stabilen Produkt, sagen wir mal, kreativ umgehen, kriege ich jetzt nicht unbedingt da Angstzustände?
Das wird eigentlich in JavaScript generell gehen, genau.
Genau, das ist natürlich, wenn du sowas machst wie React, ist natürlich alles wieder ein bisschen anders.
Weißt du, das kann doch bissl weh.

[0:34] Music.

[1:00] Working Draft Revision 572, Diese Revision von Working Draft wird euch präsentiert von Hörerinnen und Hörern wie euch. Auf patreon.com slash working draft könnt ihr uns ein paar Euro in den Hut werfen.
Aus euren Beiträgen und unseren gelegentlichen Werbeeinnahmen bezahlen wir allerleite eure Software-Abos und das Honorar unserer Audio-Producerin.
Wenn ihr euch auch beteiligen wollt, könnt ihr das unter patreon.com slash working draft sehr gerne machen.
Wir danken euch tausendfach für die Unterstützung und fürs weitere Zuhören.

Revision 572: Signals

https://workingdraft.de/572/

[1:33] Hallo und herzlich willkommen zu Working Draft Revision 572.
Heute sind am Start der Stefan.
Servus. Meine Wenigkeit, der Peter. Und wir haben einen Gast aus dem fernen Portugal zugeschaltet.
Ist Bernhard. Hallo.
Bernhard, ich weiß nicht, hatten wir dich schon mal im Podcast?
Und wenn ja, wie viele Jahre ist es her? Was ich sagen will, stelle ich doch mal vor.
Ja, danke. Ja, genau, ich bin der Bernhard und ich bin ehemaliger Student von Stefan.
Das ist schon einige Jahre aus.
Und wir sind aber seitdem in Kontakt geblieben über Konferenzen, Meetups und so weiter.
Und ich studiere selbst Mobile Computing und Psychologie. Bin da aber schon recht fertig geworden und bin trotzdem der Technikbranche immer noch, teilweise immer noch treu.
Und der Stefan hat letztens etwas sehr Schönes über mich gesagt, dass ich es liebe, konstant so Assumptions zu challengen.
Und ich glaube, das würde ich in Kombination mit meinen beiden Studien sehe das mittlerweile, glaube ich, oft als Aufgabe.

[2:40] Okay, das mit den Assumptions-Challengen finde ich ja gerade im Kontext des heutigen Themas. Eine ziemlich gute Idee. Ich will ja mal meine Karten auf den Tisch legen.
Ich stehe da so ein bisschen vor, so ungefähr wie vor Cryptocurrency und AI, dass ich so denke, ja, okay, aber wirklich so krass? Ich weiß es halt nicht. Aber alle Welt redet darüber und deswegen müssen wir halt eben auch mal drüber reden. Und zwar geht es um das breitere Konzept von Signals, was ja so in meiner User Experience irgendwie sowas ist, wie plötzlich kräht alles, was irgendwie React macht darüber rum und dann baut man das ein und das funktioniert und dann hat sich exakt nichts am Leben geändert und man macht so weiter wie zuvor. So sehen Signals für mich aus.

[3:22] Aber es ist natürlich noch alles besser, weil wenn man nicht konstant neue Dinge einführen würde, dann würde generell nichts besser werden. Aber ja, Signals ist das Thema, was ich spannend gefunden habe bei dem Thema ist, dass es genauso bei mir aufgeschlagen ist in der React-Bubble nicht, aber das anscheinend überall jetzt so...
Das große Ding ist und der Trend, auf den alle aufspringen. Also am spannendsten eigentlich gesehen bei der NG Belgium, also ich war in Belgien auf einer Angular-Konferenz eingeladen, habe dort meinen üblichen Typescript-Radanz gemacht und drei von diesen zwölf Vorträgen waren rund um Signals, also von einer Alternativimplementierung zur Implementierung, die ins Framework kommt, zu einem über generelle Konzepte, also das schlagt auch dort ganz, ganz gewaltig auf.
Und dann siehst du, dass das ja auch in Wirklichkeit das System des Futures hat, dieses Reaktiv.

[4:18] Diese Reaktiv-Funktion, keine Ahnung, wie sie es dort nennen, ja eigentlich auch sowas ähnliches ist.
Und dann ist einer vom Podcast bekannt, der Entwickler, der Marvin Hagemeister, den wir auch sehr gut kennen, der auch bei uns recht oft zu Gast war, hat dann auch Signals für Pre-Act implementiert.
Das heißt, das Ding ist überall, es ist einfach überall da, jeder will Signals haben und Signals, Signals, Signals, und ich habe einfach keine Ahnung, was jetzt dieses besondere Ding an Signals ist, warum jetzt jeder und jede darauf aufspringen will.

[4:51] Tja, Bernhard, hast du eine Idee? Ja, ich habe da einen Punkt da richtig interessant gefunden, also vor allem, dass man das erste Mal sich für mich so anfühlt, als ob wir jetzt etwas hätten, was über alle Frameworks, Libraries, wie auch immer man sie nennt, dass sich die Leute einig sind, dass jeder das haben möchte oder ausprobieren möchte und das kenne ich so nur gar nicht so wirklich.
Das interessante beim reinlesen ist aber dann, dass glaube ich, das Wort mit sehr vielen vergangenen Konzepten konnotiert ist und wenn man es sich dann genauer anschaut, ist zwar einiges ähnlich, es ist aber trotzdem wieder irgendwie jede Implementierung nur sehr unterschiedlich und da bin ich sehr gespannt, wie das dann, dieses Promise, das ich gelesen habe, kann sein, dass es sogar auf Twitter war, dass wir jetzt endlich was haben, was über alle Frameworks ähnlich funktioniert oder gleich funktioniert, ob das dann sie zu einem Gleich oder zu einem Ähnlich entwickelt und man dann erst wieder sehr, sehr, sehr aufpassen muss, mit welcher Signalimplementierung man arbeitet.

[5:47] Oder ob dann genau diese kleinen Unterschiede es wieder unmöglich machen, dass man mit unterschiedlichen Projekten kontributiert und nicht mehr zerstört, wie man richtig mag.
Erinnert mich so ein bisschen an Hooks, wie sie da in React eingeführt wurden und dann hinterher sofort alle gesagt haben, okay, das Konzept lässt sich generalisieren auf ganz normale Funktionen und dann sieht so die, Benutzeroberfläche, die API genau gleich aus, aber die Implementierung sind so dermaßen unterschiedlich, dass man linke Hand und rechte Hand auf keinen Fall vertauschen darf oder irgendwas, was für A gebaut ist, auf keinen Fall für B verwenden kann, weil dann alles den Bach runtergeht.

[6:22] Ziemlich genauso. Was ja irgendwie auch Sinn macht. Also ich meine, klar, du kannst irgendwie das zu einem Konzept hin vereinheitlichen wie Hooks, aber letztlich hat man ja so was wie Frameworks, um irgendwie eine Top-Down-Kontrolle darüber zu haben, wie Dinge funktionieren und das Konzept dann diesbezüglich anzupassen, ist ja erstmal nicht verkehrt, nur das würde ja halt eben dann...
Dann noch irgendwie zu sagen, das ist tatsächlich irgendwie ein guter Aspekt von etwas, nämlich dass es überall einheitlich ist und wo es dann halt eben nicht einheitlich ist, sondern auf so eine hinterhältige Weise dann doch unterschiedlich, wo man es halt gegebenenfalls nicht mitbekommt und sich in Schwierigkeiten baut, wäre ja dann jetzt vielleicht auch eher ein Nachteil als ein Vorteil.
Du hast da gerade was sehr interessantes angesprochen, dass Frameworks irgendwie top-down sagen sollen, wie Sachen funktionieren.
Und für mich sind gerade Signals da wieder mal komplett orthogonal dazu, Weil es ist ein Konzept, wo es um reactive data management geht.
Und außer dem Namen habe ich bis jetzt nicht groß das Gefühl, dass da irgendwas am Top-Down vorgibt, wie was zu funktionieren hat.
Sondern einfach nur, wie man weiterpropagieren kann, dass sich gewisse Daten geändert haben.

[7:31] Das sollten wir vielleicht auch noch mal sagen für diejenigen, die jetzt im Vortrag dieser Aufnahme bis jetzt immer noch nicht gesagt haben, was zum Henker geht denn hier ab.
Also es geht schon darum, Der primäre Fokus ist halt schon irgendwie so Datenhaltung in der, klassischen Single-Page-App-artigen Konstruktion mit so Sachen wie React, Angular oder Vue, wo man Objekte hat, denen man sagen kann, hey, die Welt sieht jetzt so aus und dann kriegen alle damit zusammenhängenden, mit der Datenquelle zusammenhängenden Teile einer Applikation mit, dass sich die Daten geändert haben und versetzen sich in den dazu passenden Zustand.

[8:06] Grob wie es im Prinzip seit Alters her funktioniert, mit so Sachen wie Redux und, ja, useState, ja auch zu gewissem Grad, nur halt eben heißt es hateSignal und funktioniert subtil anders.

[8:20] Also das Erste, an das mich Signals erinnert haben, waren diese auch oft und lange diskutierten Observables, wo es halt einfach hauptsächlich darum geht, du hast irgendwo ein Event, das schießt halt einen neuen Wert raus und du kannst es an einer anderen Stelle konsumieren.
Und dieses Konzept jetzt angeglichen auf diese, ich weiß nicht, ob GSX der Haupttreiber war, aber zumindest auf diese Template-basierten, aha, GSX ist ja gar nicht Template-basiert, aber auf diese, naja, Komponenten-basierten Frameworks.
Ich glaube, dass das eher so der Gedanke ist. Das heißt, dass du die Konsumation von diesem Wert mit deinem Markup direkt verbinden kannst.
Also das war meine...
Neue Sicht dieser Dinge gewesen. Wobei ich glaube, dass das eigentlich auch mit Observables gehen hätte müssen.
Und Observables sind in Wirklichkeit nichts anderes als wir Eventimiter.
Ja, naja, würde ich nicht unbedingt sagen, weil es sind ja also wenn ich jetzt an Observables denke, denke ich ja an meine wilde Vergangenheit mit RXJS und das sind ja tatsächlich keine Eventimiter, sondern ja tatsächlich lazy Datenquellen, wo ja gar nicht erst irgendwas zustande kommt, sofern man nicht subscribt.
Okay, ja, gut, das ist ein wichtiger Unterschied zum Eventimiter, ja.
Genau, also der Eventimeter ist ja dann sozusagen die, ich hau halt eben einfach alles raus, das ist halt so wie der angeklickte Button, das Observable ist halt mehr so das zielgerichtete, ich hau was raus, sobald ich weiß, dass mir jemand zuhört.

[9:43] Punkt. Und ich glaube, der Punkt ist halt wirklich der, den du gerade ansprachst, nämlich die Integration mit diesen Sprachen, wie halt eben dem React-Dialect, der JSX, dass man so die Einheit aus der Logik und dem Template herstellen kann, dass man nicht irgendwie eine extra Template-Sprache schreibt, wo man dann irgendwelche Variablen rein interpoliert und man in einer Extraschicht die Übertragung von der Datenquelle in das Template machen muss, sondern dass man einfach eine Funktion hat, sie alle zu knechten, da drin gibt's die Datenquelle, sei sie Signal, Observable oder sonst irgendwas, und man kann das direkt in sein Template, in sein JSX hineinsplicen.
Und mit Observables wäre halt natürlich das Problem diesbezüglich, dass man ja irgendwie so der Template-Funktion, der React-Komponente oder Ähnlichem, mitteilen muss, dass wenn neue Daten dort, dann bedeutet das ein Re-Rendering dieser Komponente, und das ist ja das, was so ein Signal, in der gelebten Praxis automatisch macht.
Ich subscribe darauf und das bedeutet, wenn neue Daten aufschlagen, gibt es ein Update und das würde jetzt ein Observable nicht ohne weiteres tun. Da müsstest du halt ein bisschen extra Hexerei betreiben, damit das...
Genau, entweder setState oder oder mit einem mit einem Getter-Setter Proxy-Objekt Werte setzen und solche Sachen.
Also das geht halt alles um. Das macht halt das Signal von alleine.
Beim Signal sagst du einfach, da ist der Wert und jedes Mal, wenn es eine Aktualisierung gibt, genau diese Stelle aktualisiert.

[10:58] Falls ich das richtig verstanden habe. So stellt sich das für mich dar.
Wie gesagt, ich habe das eingebaut, aber...
Ja, und ein spannender Unterschied allerdings ist, und vielleicht greife ich da jetzt schon vor, aber und helfe mir vielleicht, falls ich falsch liege, ist, dass die Erstellung dieses Signals, nicht unbedingt dem Komponentencode passieren muss. Das ist ja für mich ein ganz großer Unterschied zu den Hooks. Die Hooks sind ja doch immer sehr komponentenbezogen.
Die müssen zu Beginn einer Komponenten stattfinden oder es muss auf jeden Fall direkte Verbindung geben zwischen der Komponente und dem State oder dem Hook, den du machst und du kannst Signals irgendwo erzeugen. Das kann auch in einem Redux dort zum Beispiel sein, wo das erzeugt wird und du konsumierst es nachher irgendwo anders oder in einem Kontextobjekt oder einfach draußen in einem Modul. Du sagst, hey, du machst den Modul auf, da sind die paar Signals drinnen und du erstellst die dort und du kannst so viele Consumer davon machen, wie du irgendwie lustig bist, was natürlich solche Architekturen recht interessant machst, wo du dein State in einem File ausloggerst, generierst und genauso Dinge wie Sachen wie IsLockedIn oder sonst irgendwas halt an unterschiedlichen Stellen einfach von diesem einen Modul raussaugst, anstatt dass du diese Update-Trees und so weiter maintainen musst. Also das ist ja, glaube ich, einer dieser spannenden Selling Points, die Signals so interessant machen. Ich würde sagen, also ist nicht verkehrt, aber ich glaube, also es ist nicht Ich glaube nicht verkehrt, dass das bemerkenswert ist, aber ich.

[12:24] Glaube, bemerkenswert wird das aus der React-Perspektive.
Ja, okay, gut. Wenn du ein anderes JavaScript-Programm schreibst, kannst du überall irgendein Objekt erstellen und keinem interessiert irgendwie was.
Aber diese spezielle Rolle, dass diese Funktionen, in denen JSX sind, im Prinzip überhaupt nicht funktionieren, die Funktionen, sondern spezielle magische Factory-Funktionen für seltsame Objekte sind, die sich automatisch updaten, ist ja schon eine Spezialität von diesen Single-Page-Applikationen.
Und da kommt halt eben genau das raus, was ich vorhin meinte mit, ja, okay, gleiche Benutzeroberfläche, aber komplett unterschiedliche Implementierung einerseits, aber auch Benefits, die sich materialisieren, andererseits, weil damit das, was du gerade beschrieben hast, ein Benefit ist, musst du in einer Welt leben, wo das nicht der Normalfall ist.

[13:00] Da hast du was ganz, ganz Richtiges gesagt. Das erinnert mich wieder daran, dass eigentlich das, wie wir React schreiben und machen, ja sehr, sehr stark oberflächlich getrieben ist. Und das, was darunter passiert, eigentlich ganz was anderes macht.
Eben gerade auch Hookshooks ist in Wirklichkeit nur eine Bookkeeping-Tabelle mit Statusänderungen, die Subparmetrikern, grob gesagt. Ja, so ist es, ne? Ja, okay. Gut, okay. Dann habe ich das doch halbwegs gut kapiert. Also, und du hast natürlich recht, also dass man Werte aus einem Modul lädt und schreibt, das wird eigentlich in JavaScript generell gehen, genau. Das ist natürlich, wenn du sowas machst wie React, ist natürlich alles wieder ein bisschen anders.
Das ist richtig. Weißt du, das kann doch ein bisschen weh.

[13:54] Es ist sehr interessant, was du da gerade gesagt hast, weil für mich hat das am Anfang, also ich habe auch gelesen, ich glaube von Ryan Carniato, der Solid erstellt hat, dass das dieser Benefit ist, dass man State und Komponenten nicht co-alignen muss.
Und ich komme zumindest in der Webentwicklung aus sehr frühen AngularJS und Angular-Zeiten und jetzt sind die Argumente gerade für mich auch ein bisschen nachvollziehbarer geworden, bis ihr zwei darüber geredet habt, weil natürlich sollte man Sachen auch außerhalb von Komponenten Tree irgendwie verwalten können. Und dass das halt closely oder sehr sehr tightly gekoupled ist, stellt sich für mich als Developer Experience halt die Frage.
Das sind wieder diese Polarisierung von zwei Seiten, wo man sagt, hey, so muss State gelöst werden oder so muss State gelöst werden. Und mir ist gerade aufgefallen, ich weiß gar nicht 100 Prozent, wo ich hin möchte mit dem. Aber es ist die Realisierung, die du auch gerade angesprochen hast, dass das nicht normal ist, dass man wirklich in State komplett den Komponenten denkt, das aber irgendwie normal geworden ist, das was jetzt wieder aufbrochen wird. Ja, und das ist halt so ein bisschen, warum ich da so ein bisschen ratlos davor stehe, weil mir genau der gleiche Gedanke gekommen ist, Nanu, das hört sich doch an wie etwas, das wir früher schon mal hatten und es gibt ja auch irgendwie, sagen wir mal, theoretisch gute Gründe, warum man das halt nicht mehr macht. Ich erinnere mich noch sehr gut, wie mir zum ersten Mal jemand React verkauft hat. Da saß ich auf irgendeinem sehr unbequemen Stuhl in in Berlin und irgendwer hatte da irgendeinen Talk und erzählte das und dann dachte ich so, ah ja, das ergibt Sinn.

[15:24] Und jetzt kommt halt eben einfach das, was man dann halt eben früher in AngularJS oder so mit rumgespielt vor ganz, ganz langer Zeit mal halt eben so ein bisschen wieder und natürlich macht das halt eben auch Sinn, weil das ja offensichtlich früher auch funktioniert hat.
Und wie immer oszilliert halt so die JavaScript-Welt hin und her zwischen, man macht das jetzt so, man macht es jetzt so, jetzt macht man es wieder anders, jetzt macht man es wieder so.

[15:44] Was halt so der Grund ist, warum ich das so ein bisschen davorstehe und mir so denke, ja, okay, kann man machen.

[15:49] Aber warum denn so viele Artikel darüber schreiben?
Also, kann man nicht beschreiben, hab ich jetzt gemacht, das funktioniert auch sehr gut aus dem und dem Grund, und ich hab diese und jene Trade-offs, und guck mal, könnt ihr auch so machen. Halt dich für eine gute Idee.

[16:04] Gut, also, da ist halt einfach so, dass jetzt ... Ich glaub, das, was der Bernhard gerade gesagt hat mit Solid Chess, ist gar nicht so unwichtig, weil Solid Chess hat einfach gesagt, früher auch nicht immer so, und kombiniert das mit diesem Reactive Approach von Observables oder Signals oder wie auch immer du das nennen willst. Und auf einmal hast du ein neues Framework, das wirkt irgendwie ein bisschen leichter, räumt mit ein paar nervige Sachen auf, von denen alle schon genug haben, und ja, probiert es einmal, macht es einmal, und dann finden das Leute cool, dann gibt es recht viel Buzz, dann wird recht viel darüber gesprochen, und dann müssen natürlich irgendwie andere Systeme nachziehen oder auch nicht. Und vielleicht war das einfach so naheliegend, dass man das nachher in lauter andere Frameworks und Tools mit implementiert. Und deswegen ist das jetzt gerade der neueste, heißeste Trend, falls das ein Trend ist. Also ich sehe das eher locker.
Also das Einzige, was ich mir gedacht habe, ist, auf ein paar Implementierungen hinbezogen, was z.B. Angular implementiert, jetzt Signals komplett from scratch, Framework inkludiert.
Und ein Kollege von uns, der Michael Latki, hat ja das gleiche Konzept auf RxJS Observables basiert schon gemacht. Also es gibt schon eine Angular Implementierung davon als Plugin oder.

[17:23] Als Zusatzbibliothek, die auf RxJS baut, das ja quasi mitkommt mit Angular, weil das war sowieso immer noch die spannendste Entscheidung, wo es so gesagt hat, du machst dieses klassenbasierte, komponentenbasierte Framework und hast aber reaktive Datenströme irgendwo in deinen Klassen drinnen, damit du irgendwie Daten hin- und herschicken kannst. Er hat das halt jetzt hochgezogen von den Klassenmethoden rauf ins Template, hat mit ein paar Bild in Framework internes aufgeräumt, hat das Ganze performanter und schneller gemacht, hat bewiesen, dass das eigentlich dort ein besseres Konzept ist für das, was Angular machen möchte. Und Angular sagt jetzt, passt, coole Idee, schmeißen wir alles weg, machen wir neu. Dabei wäre es ja eigentlich schon da gewesen. Also das ist eine Frage, die man nicht beantworten kann. Und vielleicht eine größere Frage zu dem, was du jetzt gesagt hast, ist das, was so neu ist, ist ja das Ganze jetzt gar nicht.
Also das Erste, an das mich das Ding erinnert hat, wie ich es zum ersten Mal ausprobiert habe oder zum zum ersten Mal angeschaut habe, war Knockout-Chess.

[18:28] Das war mein erster Gedanke. Das war halt nur ein bisschen rudimentärer, sag ich mal.
Da hast du halt noch Markup und JavaScript voneinander getrennt.
Wow, wer hätte das gedacht, dass das geht? Und hast halt aber genauso einfach Daten auf Knockout Observables rausgeschickt und irgendwie in deinen Markup reingebracht.

[18:56] Aber das war ja immer noch dann ein manuelles Subscriben, wenn ich mich recht erinnere, oder?
War das ein manuelles Subscriben?
Weil ich meine, der große Unterschied ist ja dieses automatische Subscriben von den Signals, auch in Abgrenzung zu den Observables, die du ja vorhin daraus gebraucht hast, dass du halt eben die benutzung in der Funktion ist ein implizites Subscriben mit passiert.
Ja, das stimmt, da hast recht, weil tatsächlich musst du, also die Knockout-Observables waren ja, glaube ich, sogar Pate für diese RxJS-Observables.
Oder kommen aus der gleichen Ecken oder aus dem gleichen Sumpf, sagen wir mal so.
Naja, oder man kann das ja auch so sagen, die verfolgen das gleiche Ziel, wenn wir es mal mehr wertfrei formulieren wollen.
Ja, die verfolgen das gleiche Ziel, das ist sehr schön.
Das Knockout.js war ja sehr populär zu der Zeit damals. Und es gibt ja immer noch ziemlich viele Anwendungen da draußen, die das immer noch benutzen.
Und ich würde halt wirklich sagen, so nach jQuery ist halt so Knockout.js, dass der Kandidat Nummer 1, wenn nach irgendeinem Vortrag irgendwer zu mir kommt und so kleinlaut zugibt, in Airquotes, wir benutzen noch, dann ist es entweder jQuery oder Knockout.
Als ob damit irgendwas verkehrt wäre, zumal ja wirklich Knockout, wo du ja gerade die Verwandtschaftsbeziehung hergestellt hast, ja im Prinzip einfach nichts weiter ist als eine Implementierung des neuen heißen Scheiß.

[20:16] Ja, und ich finde es cool. Ich schaue mir dort wieder ein paar Beispiele an und denke mir, das ist super, ich würde es wieder nutzen.
Das kannst du wahrscheinlich, Peter, da sind wir auch glaube ich jedes Mal, wenn wir miteinander reden, wahrscheinlich kannst du das heute mit ECMAScript Next oder Sex oder was auch immer, welchen Sprachkonstrukten und ein bisschen Wissen zu dem, wie vorher die Welt war und wie sie heute ist, kannst du wahrscheinlich ein recht fesches, elegantes und gleichgewichtiges Framework daraus machen und in Sachen, hey, du willst geschwind ein paar interaktive Elemente auf deiner Seite haben, was ja jetzt auch wieder der Trend ist, wo jetzt auch wieder alles hingeht, so auf die Art, hey, lass du es statisch und du hast ein paar so vereinzelte Punkte, wo du dich ein bisschen herumhacken kannst.
Ist das ja perfekt. Das ist ja genau das, was du willst.
Also ich glaube, ich werde mir das wieder anschauen.

[21:04] 66 Kilobyte minified, also da kann man sicher was machen. Mhm, ja.
Na ja, man braucht ja nicht mal irgendwie fancy Next und so Zeug.
Weil ich meine, jetzt, wo wir irgendwie rausgearbeitet haben, so ein bisschen, was diese Signals am Ende für einen, ja, Effekt, so grob haben auf die gelebte Entwicklung.
Wir können ja mal so ein bisschen auch den Schwenk in die Implementierung machen.
Weil die ist ja eigentlich auch nicht wirklich magisch.
Also, der schwierige Part ist die, ähm ...
Ist ja das Einhängen in diese, wenn Update dann Folge-Updates auslösen.

[21:38] Redest du jetzt von der Implementierung, die du als Entwickler machen musst, oder redest du jetzt von der Implementierung des Signals an sich?
Die der Signals an sich, weil die der Entwickler ist ja tatsächlich einfach nur, da gibt es ein Objekt, da subscribe ich drauf, auf die eine oder andere Weise, die sieht ja im Moment auch im Prinzip überall gleich aus, und dann fallen da Daten raus und Punkt.
Das ist ja eigentlich, was ein Signal ist.
Und der wirklich spannende Part ist ja dieser automatischen Anbindung.
Indem ich dieses Signal anzapfe, weiß ich, dass dann meine Komponenten oder sonstigen Programmteile automatisch sich updaten, wenn das Signal einen neuen Wert liefert.
Das ist ja der magische Teil, das ist ja auch der schwierige Teil, eigentlich würde ich mal behaupten, der komplizierte Teil, der Framework-spezifische Teil, weil eigentlich ist es ja bloß ein Container, wo irgendwie ein Objekt drin wohnt.
Und wenn das Objekt ausgetauscht wird, dann ist halt Update.
Und was dann halt eben aus dann ist halt Update folgt, Das ist dann halt eben der framework-spezifische, fallspezifische Mechanismus.
Mhm.
So, das heißt, die sind ja nicht mal irgendwie besonders speziell.
Ist ein Containerobjekt mit irgendwie einer Methode, wo man sagen kann, hier, hast du ein neues Objekt.
Kann eine Methode sein, kann irgendwie ein Setter sein.
Und that's it. Der spannende Part ist halt nur, okay, wie krieg ich jetzt irgendwie meine restliche Logik, da direkt drangekoppelt? Auf eine implizite Weise meistens.

[22:57] Ja, und das wäre jetzt interessant, ich habe keine Ahnung, wie das funktionieren könnte.
Also da kenne ich mir einfach mit Framework-Internes zu wenig aus.
Es gibt einen spannenden Artikel von den Preact-Leuten, die versuchen, das zu erklären.
Aber ich habe es eigentlich gar nicht verstanden.
Naja, das kolliegt halt eben auch daran, dass du ja in React wirklich eine sehr seltsame Konstruktion, weil du hast deine Funktion und da ist dein JSX drin und die Erklärung ist ja, wenn die Funktion neue Parameter bekommt, dann updatet sich dieses Template. Aber ganz so ist es ja nicht so.
Es ist ja mehr so eine Factory-Funktion mäßiges Ding.
Und was ja passiert ist, dann der Subscribing-Mechanismus sorgt dafür, dass irgendwelche Ereignisse imitiert werden, und die sind dann natürlich angebunden an das resultierte Objekt.
Und sozusagen, wenn das Ding weiß, ich bin eine Factory-Funktion für irgendwas, ist das ja gleich einer althergebrachten Klassen-Constructor-Funktion in JavaScript, die dann halt eben auch weiß, aha, ich hab hier was produziert, zudem hab ich eine Referenz, also wenn ich gecallt werde, kann ich irgendwie Kram machen.
Das ist sicherlich jetzt nicht trivial oder so, aber es ist halt am Ende auch irgendwie nur so, man muss halt gucken, wie wird das Ding gebaut, und dann bindet man sich da dran.
Das ist halt im Falle von ... Okay, das heißt, du haust die wahrscheinlich in den Renderhook rein, oder was war's, ShootComponentUpdate, glaub ich, war so eine Funktion, die evaluiert hat, ob es dort eine Update geben soll.

[24:21] Und ich glaube, mit der hat man das nachher bewerkstelligt. Ja, also die Preact-Signals, wenn man da Direct-Implementierung für rausholt, dann monkeypatchen die da eine ganze Menge an React herum, ersetzen die Create-Element-Funktion, hauen da irgendwo was in Prototypen, habe ich meine nicht auch gesehen zu haben, wo man jetzt normalerweise sagen würde, es ist ja irgendwie voll spooky, aber wenn ich jetzt irgendwie so denke, da ist es irgendwie so ein relativ stabiles Ding wie React, und da sind die Leute da am Werk, die Preact machen, die sind ja keine Vollhühner, die wissen ja extrem genau, was sie tun und wenn, extrem kompetente Leute mit einem extrem stabilen Produkt, sagen wir mal, kreativ umgehen, kriege ich jetzt nicht unbedingt da Angstzustände.
Ja, es ist ja gerade so, die Projektmenschen, die verstehen ja beide Codepasen wirklich gut, also die verstehen ja React ziemlich gut und Preact ziemlich gut. Das ist ja wirklich, ja vielleicht Dinge drinnen, wo man sich halt denkt. Wow, da habe ich eigentlich Bauchweh, weil das wirkt jetzt nach einem bösen, dunklen Zauber, den ich nicht verstehe. Aber die Realität ist halt, naja, wenn du die Nebeneffekte abschätzen kannst, dann machst du es halt. Und so tun sie es dann auch dort.
Ja, und vor allen Dingen, böser, dunkler Zauber ist ja letztlich auch nichts weiter, als irgendwie ein Mittel, das du anwendest.

[25:42] Und nur weil's böser, dunkler Zauber ist, heißt das nicht, dass es nicht böse, dunkle Mächte gibt, auf die dieses Mittel anzuwenden genau die richtige Maßnahme ist.
Ja, ja, ja, das stimmt.
Also irgendwie so ein Anti-Pattern ist immer ein Anti-Pattern in einem bestimmten Kontext.
Es sei denn, es löst unter den spezifischen Constraints irgendwie genau dein Problem.
Du hast auch schon mal Eval benutzt oder New Function geschrieben.
Ständig. Ja, nicht stetig, aber hast du mal gemacht.
Ja, na doch, ich mach das wirklich ständig. Aber ich habe halt auch andere Use Cases, ne?
Das ist halt das Ding.
So, wir müssen halt irgendwie hier, weiß ich nicht, unser Kunde kann da halt irgendwie so Javascript eintippen, und das muss halt eben evaluiert werden, weil Gründe für Datenanalyse und Zeug.
Ah, okay. Gibt es da irgendwie ein Risiko? Ja, der kann höchstens seine eigene Datenbank frittieren.
Ja, wunderbar. Schreibt halt eine Warnung drüber und go.
Ja, das ist richtig. Du baust ein Profi-Tool und dann kann man sich halt damit auch ins Knie schießen, ist okay.
Ja, das ist richtig. Also ich denke mir auch, in Wirklichkeit passiert ja dort nur das.

[26:57] Über dieses Monkeypatching, was ja dann zum Beispiel Frameworks oder Bibliotheken wie MobX, das ja auch in so eine Richtung geht, irgendwie über Decorators oder ähnliches lösen.
Also da musst du halt, hast halt wieder diesen manuellen Step da drinnen und die Entscheidung wird da halt abgenommen, indem ja diese zwei, drei Funktionen gemonkeypatched werden.
Das habe ich tatsächlich nie benutzt als MobX, muss ich ja sagen.
Also, ich versuche jetzt gerade MobX wieder herauszukriegen, also ich habe es tatsächlich in einem Artikel von Bernhard, den er geteilt hat, ist mir das auch aufgefallen.
Der Bernhard hat gerade aber ein Technikproblem, sonst würde er da sicher sofort rein springen.
Aber wenn ich mir das jetzt anschaue, ich muss es jetzt wieder richtig herausfinden.
Das ist nämlich auch schon eine Zeit lang her.

[27:48] Gibt es dort die Observer-Funktion und die Observer-Funktion ist nichts anderes als wie ein Decorator-Function, wo du nachher deine JavaScript- oder JSX-Komponente drinnen hast. Und was die macht, ist genau das Gleiche, dass sie sagt, hey, bevor dort dieses Render passiert, weiß ich, da drinnen sind irgendwelche Referenzen zu meinen Updates und ich kann diese Komponente speziell triggern oder speziell re-rendern, wenn in dieser reaktiven Datenklasse, die ich dort noch bei den Klassen verwendet, irgendein Update passiert. Es ist halt nur explizit. Das heißt, ich schreibe Observer und mache dann meine Komponente oder wenn ich eine Klassenkomponente habe, habe ich halt schon einen Decorator oben drauf, den ich über die Klasse schmeißen würde, weil falls man TypeScripts verwendet. Aber in Wirklichkeit macht es genau das. Es wrappt die eigene Komponente in dieses Update-Konstrukt, das dann reagiert auf diese Dinge, wenn irgendwo ein reaktiver Datenstrom neue Events liefert. Und diese Entscheidung wird dir halt abgenommen durch diese Monkey-Patch-Funktion in React und Project.

[28:56] Genau. Und Hooks, gleiche Geschichte. Normalerweise müsste man ja auch Funktionen hookable machen, aber das macht halt eben React in dem Fall eingebaut, Projekt auch, halt eben automatisch.
Ja, genau. Aber also, soweit ich jetzt gelesen habe, die letzten Tage über Signals und Co.
Und auch von Michael Westgate, glaube ich, hat er auch sehr viel Zeit verbracht, damit diese Auto-Detection in MobX einzubauen.

[29:24] Aber es kann auch sein, dass ich mich da jetzt täusche, weil du hast, glaube ich, einen Einwanderer gegenstellt.
Nein, also ich habe mir nur versucht zu erklären, warum eben jetzt Signals anders ist, als es für MobX damals war.
Weil ein Ding, das halt bei MobX auch schon immer war, mit dem MobX groß, ich will nicht sagen, hausieren gegangen ist, aber dass diese USP von MobX war, war, dass du halt wirklich sehr fein granulare Updates auf deinen Komponenten gehabt hast.
Eine wunderschöne Visualisierung geben über diese DevTools, die gesagt haben, nur dieses eine kleine Teil wird jetzt aktualisiert, nicht der ganze Rest. Was halt dagegen gesprochen hat, war immer diese, also ich glaube, das hat ja mehrere Megabyte gehabt, diese Bibliothek.
Und wenn ich mir jetzt den Code anschaue, der ist halt auch noch teilweise ein bisschen älter, weil Mobex halt einfach out of fashion gegangen ist, witzigerweise, um halt anderen Dingen den Vorzug zu geben, machen die das halt wirklich so, dass sie so observable oder Observer-Decorator-Funktionen haben. Das heißt, du holst dir so eine Decorator-Funktion raus, die kann in deiner Klasse auch tatsächlich ein TypeScript Decorator sein und schreibst da drin deine Functional Component oder deine React Komponente. Das heißt, du sagst, hey, du hast jetzt deinen Timer.

[30:46] Ist gleich Observer, Closure da drinnen und du gibst dir Komponente zurück und genau über diese Observer Methode werden diese reaktiven Updates getriggert. Das heißt, über diese Observer-Methode weiß Mobex sehr, sehr gut, wo diese Updates stattfinden.
Das sind aber rund um die Komponente und ich glaube, dass genau dieser Teil von, diesen Auto-Detections übernommen wird. Also wenn jetzt das Projekt sagt, ich verwende dort ein Signal, dann überschreiben sie halt diese zigtausend Funktionen oder monkey-patchen irgendwelche internen Funktionen, um genau diese Entscheidung abzunehmen, ob, ob jetzt dort ein reaktiver Datenstrom drinnen liegt oder nicht.

[31:30] Das ist mein Verständnis dieser Dinge. Okay, das ist interessant, weil ich tatsächlich da habe ich keinen Unterschied gesehen, weil ich es auch im Lied gelesen habe.
Ich habe mich eher dort gesehen an der direkten Integration in das ganze DOM-Updating.
Das ist quasi das, was dann Solid, Projekt und Co. optimieren, Weil sie dann über diesen Compile-Step quasi eingreifen können, dass sie möglichst optimiert die Updates auf den DOM durchführen, auf Basis, wann sich bei den Observables was ändert.
Sie greifen den Compile-Step ein?
Also quasi durch, denn das hat, soweit ich gestern noch gelesen habe, hat das VELD angefangen, dass die halt das so kompilieren, dass sie halt direkt das DOM-Updating machen, oder die ganze Lüge an.
Ja, weil du das Weltverstehs, das Welt ist im Grunde dieser eine Compiler, der halt auch sagt, hey, du, ist das ein toller Zeichen, das ist so irgendwie weil jedes JavaScript-Syntax, aber wir geben jetzt da mal eine Bedeutung drauf, ne?
Und macht dort was. Und das würde natürlich Sinn geben, wenn ich während dem JSX-Kompilat selbst, sage, hey, Moment, ich hänge mich dort noch ein bisschen rein. Finde ich spannend.
Naja, und du kannst das ja sowieso machen, weil ja qua Konvention die Hooks, mit denen du ja dann Signals und ähnliche State Manager auf die zugreißt, die haben ja auch eine Namenskonvention.
Die fangen ja alle mit Use-Handy-Pass an. Ja, ja. Puh.

[32:59] Das hört sich so sehr stabil an. Das ist unglaublich. Ja, ja. Ich denke mir das gleiche.
Hey, das ist immer noch besser als diese regulären Ausdrücke auf Function Prototype to String von AngularJS für die Dependency Injection.
Wie funktioniert das eigentlich alles?
Ich bin wieder an dem Punkt, das ist immer, wenn ich mit irgendeinem von euch zurecht komme, wo ich mir denke, warum bin ich eigentlich jetzt seit 20 Jahren in der Softwareentwicklung und bin jetzt, keine Ahnung, Kartoffelgärtner oder was weiß ich, Kartoffelbauer im Wald oder sonst irgendwas.
Okay, aber vielleicht eine gute Überleitung, weil Bernhard, du hast eingangs im Vorgespräch gesagt, dass du findest, die Angular-Implementierung sei die elegantere und ich habe natürlich absolut null Ahnung, wie die Angular-Implementierung ausschaut, ich wäre aber sehr interessiert.

[33:53] Ja, vielleicht hole ich da noch ein bisschen aus. Ich habe auf Hackernews, mein Partner, wenn es nicht du bist, zu meiner Karriereentscheidung jetzt über die Frage.
Die Verlinkung zu diesem Tweet sind, ich werde dir den nochmal schicken, Was dann gegangen ist, dass je nachdem, wie man in welchen Reihenfolgen oder wie man die Sequence verwendet, das war in Solid, dass dann quasi im Compiler also was anderes gemacht wird damit und dann entweder da die UI reactive ist oder nicht.
Und das ist wirklich ein bisschen so eine Subtle Difference, die mir jetzt auch nicht unbedingt gefällt, das ist aber jetzt kein Problem per se von Signals, sondern von bestimmten Implementierungen.
Und wenn man die unterschiedlichen Signale mit den Implementierungen vergleicht, da machen sie ja die einen machen es über Get-Done-Set-Date, die anderen machen es über ein Function-Call, also wie man quasi auf das Signal zugreift, oder wie man neuen Werten in das Signal setzt.
Und da bin ich auf diesen, das war tatsächlich ein Artikel auf ITnext, da bin ich drauf gekommen auf Angular V 16 Next 7 Version, wo er drüber geschrieben hat, wie jetzt die Signals ausschauen in Angular 16 oder im aktuellen RFC, glaube ich.

[35:17] Und da hat mir unglaublich gut gefallen, dass es eine Trennung gibt zwischen Writable Signals und Read-only Signals, will ich mir ein, dass sie heißen.
Und was mir aber am besten gefallen hat, waren diese drei Methoden bei Writable Signals, wo es gibt Set, Update und Mutate.

[35:36] Weil ich, der nicht jetzt direkt, der nicht begonnen hat im Web, oder ich würde mich nicht als Web-Native bezeichnen, Für mich sind Spreading und einzelne Properties zu ändern, so schön oder elegant das auch ist.
So verwirrend habe ich selber erlebt, dass das für Menschen ist, die – ich weiß nicht, wie gern du das Wort Fullstack magst, Stefan, aber – die mit anderen Sprachen auch arbeiten müssen.
Und jetzt gibt es in dieser Angular-Implementierung dieses Set, das quasi einfach den Wert überschreibt.
Dann gibt es ein Update, wo man einen neuen Wert auf Basis vom alten derived.
Das hat eine neue Signatur, eine T als Rückgabewert. Das heißt, da leitet man wirklich den neuen Wert ab vom alten.
Und dann gibt es ein Mutate, wo der Rückgabewert void ist. Das heißt, da ändert man etwas, z.B. wenn man eine Liste oder ein Array hat.
Und dann wird aber im Hintergrund genau diese Reactive Chain getriggert.
Und das hat mir unglaublich gut gefallen, weil das für mich als ein Mensch, der sehr in Developer Experience interessiert ist, aufgrund meiner Studienkombination, einfach, eine saubere Trennung ist zwischen den drei unterschiedlichen Arten, wie man interagieren kann mit einem Signal oder wie man auf ein Signal schreiben kann, abgebildet in der Typesignatur der Methoden.

[37:03] Okay. Okay.

[37:06] Ich tu mir noch ein bisschen schwer, dass ich mir das vorstelle, aber ich weiß zumindest, wo du herkommst, weil...
Also ich gehe ja auch gerade diesen einen Hacker-News-Thread durch, den wir auch verlinken werden, wo eben auch viele Leute sagen, hey, Moment mal, was da jetzt passiert, ist, dass wir in einem unidirektionalen Datenfluss uns Punkte erlauben, wo wir den State ändern können, der in Wirklichkeit unabhängig ist von dem, was eigentlich das Framework so macht.
Also ich glaube, das ist ja die ganze Hexerei bei Signals.
Das ist ja auch das, was wir jetzt, glaube ich, versucht haben, in der letzten halben Stunde herzuleiten.
Und da ist es natürlich gut, wenn du das hast, wenn du wirklich explizit sagst, hey, Moment mal, du bist jetzt in einer anderen Welt, und das ist jetzt unabhängig von dem ganzen Rest, dass du halt auch die Dinge explizit machst und sagst, was da passiert.
Und das verstehe ich gut. Ich schätze aber dann trotzdem, dass im Hintergrund was passiert, also ich meine, die Templates werden ja ahead of time kompiliert, nehme ich an, also ich glaube, dass man Just-in-Time-Template-Compilation macht in Angular ist eh nicht mehr der Fall, ich weiß nicht, ob das überhaupt noch geht.
Du wirst wahrscheinlich auch genau das Framework sagen, hey, und da passiert das Update, und, da hängen wir sich rein.

[38:26] Ja, genau, ich glaube wir haben ein bisschen aneinander vorbeigeredet, weil mir ist es eher um das Ab, also um das einem Signal einen neuen Wert geben.
Okay. Und da gibt es ja diese Implementierungen, zum Beispiel, dass es bei Projekt arbeitet man mit dem Punkt Value, soweit ich weiß. Und dann ist das jetzt bei Solid über die Funktion. Und das sind diese unterschiedlichen Implementierungsdetails. Und das hat mir gefallen bei Angular, dass das aufgeteilt ist auf die drei Arten, wie man interagieren kann mit Wobei ich da glaube ich gleich hinzufügen kann, dass, ich glaube, dass wir uns da einig sein könnten, dass genau dieses direkte Interagieren mit diesem einzelnen Verb ja genau das Argument war, warum wir diesen Unidirectional Dataflow haben möchten, oder wie der Dataflow gesagt hat, wie ein React verkauft worden ist, und da habe ich irgendwie total das Gefühl, es Es fehlt eine ganz wichtige Komponente, weil wenn wir jetzt wieder anfangen den All-Apps-Signals zu schreiben, direkt, natürlich haben wir dann eine super Reactive-Chain, aber zu wissen wo das herkommt und vor allem bei meinem Team arbeite ich mit mehreren Personen, die entwickeln.

[39:48] Das stelle ich mir sehr spannend vor. Ja, absolut. Also ich glaube, dass das genau der Knackpunkt ist, Peter, was du eingangs gesagt hast.

[39:56] Es ist nicht neu, wir haben jetzt lange Zeit etwas anderes gemacht. Warum ist das jetzt da und ist das überhaupt okay, was dort worden ist?
Also ich glaube, das kann man jetzt echt in Frage stellen. Also ich habe da jetzt genau zu dem Punkt auch einen Artikel gefunden von Elm, also von dieser funktionalen Programmiersprache, die noch Javascript kompiliert, also quasi das Frontend-Heskel, die halt gesagt haben, hey Moment, das haben wir ausprobiert und wir machen das jetzt nicht in Favor von so einem unidirektionalen Datenfluss. Also ich will nur kurz klarstellen, ich wollte jetzt nicht sagen, dass irgendwie ich jetzt eine Frage stellen möchte, ob man das so machen kann, weil es gibt da draußen genug funktionierende Software, die das verwendet, so schlimm wird es schon nicht sein, sondern mehr so die Frage ist, warum wird das jetzt in einem Maße als, ja, als Neuheit beworben?

[40:48] Das ist eigentlich so das. Ich denke halt, soll halt jeder nach seiner Fasson glücklich werden, macht er ja State Management, wie er wollt. Und grundsätzlich ist es so, keine Regel ohne Ausnahme.
Das heißt, nicht jedes Problem ist mit unidirektionalem Datenfluss irgendwie optimal zu erschlagen.
Einen Ausweg zu haben, um es anders zu machen, um Dinge global zu managen, ist hilfreich.
Aber warum das jetzt irgendwie so beworben wird, warum das jetzt grad so das Hype-Thema ist, dass es uns irgendwie auf die Podcast-Agenda gerutscht ist, das ist das, wo ich mich ein bisschen wundere.
Also, ich glaub einfach, dass ... Also, jetzt nach dem Gespräch, glaub ich, versteh ich's.
Ähm, nämlich, dass einfach ...

[41:27] Immutable ist super. Und unidirektionaler Datenfluss ist auch super.
Aber hier und da gehen die Dinge halt einfach in den Weg.
Und meinem Gespür nach ist Signals halt dann deswegen cool, weil du für small scoped Aufgaben relativ gut sagen kannst, da sind die Daten und da wirst du es anzeigen und fertig.
Also ich glaube, dass es genau für das einen Ausbruch gibt. Aber ich meine, wenn ich jetzt meine React-Brille aufsetze, könnte ich sagen, nimmst halt You State.
Ja. Und da gibt es eine richtige, also da gibt es auf jeden Fall eine Sache, die mir richtig gut gefällt bei den Signals, das ist das Automatic Dependency Tracking. Statt dem Dependency Array wissen die selber, wo die Änderungen herkommen. Und das finde ich auch einen schönen Selling Point von Signals.

[42:21] Ja.
Ja. Ja, das versteh ich. Ja, ist natürlich mit dem Dependency Array auch so eine Sache.
Ähm, also, ich bin ja weiterhin noch immer nicht 100 Prozent davon überzeugt, dass das so in der React-Welt die beste Idee war, die Klassen links liegen zu lassen.
Wenn ich da so an UseEffect denke und das Dependency Array von dem, wo halt ...
Also, ich glaub, ich hab nirgendwo so oft hinterstehen, irgendwie ES-Lint-Ignore.
Äh, an genau der Stelle, weil es halt eben im Allgemeinen richtig ist, das Dependency Array korrekt auszufüllen, soweit, dass ich auch eine Linter-Regel haben will.
Aber es gibt Umstände, wo das nicht der Fall sein sollte. Dann muss da eine ESLint-Direktive drinstehen plus ein L-langer Kommentar, der erklärt, warum diese Direktive da steht.
Ich sag's euch, React-Klasten in CoffeeScript, das wird the next big thing.
Also, da fang ich jetzt schon drauf an. Ganz ehrlich, das ist echt nicht schlecht.
Pass auf, nicht mit CoffeeScript, mit Decorators, die es jetzt in standardkonformer Version für ECMAScript als Ganzes gibt.
Die ein Game Changer sein könnten für solche Geschichten.
Weil du Dinge wie Observability an Klassenmethoden annotieren könntest, wenn du nicht vor Kurzem gesagt hättest, dass Klassen doof sind und nach Lulu riechen.
Ja, wie gut, dass ich meine Meinung ändern kann.

[43:45] Aber ja, ähm, ähm, Ember hat das so gemacht, das Klimaframework.
Hat einfach das Tracked-Attribut vor Properties geschrieben, die getrackt werden sollen.
Und dann hast du die ganze Reaktivität gehabt.
Supercoole Sache. Ja, und was sehen wir da wieder? Man kann das so oder so machen.
Und ob's dann gut funktioniert oder nicht, liegt halt echt nicht daran, ob du dich jetzt entscheidest für Redux oder UseState oder Context oder Signals.
Ich glaub, das hat einfach damit, mit dem Erfolg des Projekts, exakt überhaupt nichts zu tun.
Und jetzt kann ich ja mal hier meine Grand Unified Theory of Library Churn raushauen, warum ich glaube, dass das jetzt gerade so gehypt wird.
Das ist nämlich, was ich an mir selbst beobachtet habe, als ich diese Signals implementiert habe in meiner mittelgroßen React-Applikation.
Jetzt kommt. Mein Redux war doof und war halt oll. Das habe ich auch so nach altem Muster noch geschrieben, ohne das Redux-Toolkit.
Das war also definitiv doof. Überall musste ich dran schreiben, ja, als Legacy und bla und Keks, war alles ganz unumständlich. Und Signals sind der neue heiße Scheiß.
Gehe ich halt eben hin und schmeiße das alte raus und baue das neue ein. Stellt sich raus, ist danach besser.

[44:50] Aber warum? Ja, das war jetzt schwammend. Warum ist das jetzt besser?
Hast du irgendeinen Eindruck, dass es jetzt besser ist? Ja, ist es definitiv. 100 Prozent.
Und weißt du, warum? Weil ich es zum zweiten Mal geschrieben habe.
Hahaha. Ich bin mir 100 Prozent sicher, wenn ich jetzt einfach gesagt hätte, ich schmeiß jetzt altes Redux raus und nehm jetzt Redux Toolkit und verwende das damit, schreib das damit neu.
Oder mach das alles jetzt mit UseState, mal das alles in einen Kontext.
Oder nehm irgendeine andere State-Management-Lösung.
Schaffe ich es halt trotzdem nicht, das Alte 1 zu 1 ins Neue zu portieren.
Notwendigerweise mache ich dabei ein paar Sachen besser.
Kann gar nicht anders, weil ich ja weiß, dass das irgendwie schlecht ist.
Und das würde halt übermenschliche Disziplinen erfordern, die alten, schlechten Sachen auch 1 zu 1 zu übernehmen.
Wir haben ja da quasi wirklich, es ist ja im Prinzip wie in der Psychologie, dass das ja mit den kontrollierten Experimenten und so der Nachweisbarkeit von irgendwelchen Sachen halt echt eine schwierige Angelegenheit ist.
Weil du halt eben nicht aus deinem eigenen Schädel rauskommst.
Und deswegen glaube ich halt eben, die Signals haben meinen Code besser gemacht, aber das lag nicht an den Signals.

[45:52] Jetzt wäre natürlich spannend, ob das Kollektiv der Web-Entwicklerinnen und Web-Entwickler da draußen die gleiche Erfahrung hat wie du, wo sie sagen, hey Moment mal, jetzt wo Signals einsetzen, wird alles besser.
Eben genau, genau weil sie es zum zweiten Mal schreiben. Und vielleicht ist das auch genau der Grund, warum wir ständig neue Dinge besser finden in den letzten Jahren als wie die davor.
Das ist meine Theorie.
Das ist deine Theorie.

[46:21] Also, ich will jetzt nicht sagen, es gibt gar keinen Fortschritt, aber ich würde sagen, ein großer Faktor im Fortschritt, im Gesamtfortschritt, findet auf individueller Ebene statt, dadurch, dass man eben Dinge neu betrachtet, nochmal neu schreibt, einen Grund hat, Dinge zu refactoren, wo man sonst eben nicht zukommen würde, weil, na, passt schon, ist gut genug, habe ich jetzt keine Zeit zu.
Das kannst du halt nicht auseinanderziehen. Und deswegen bin ich da halt relativ von überzeugt, dass das halt damit zusammenhängt.
Also, viel von der Verbesserung ist halt auch einfach, dass ich im Rahmen dieses ganzen Umbaus gezwungen war, ein paar Komponenten einfach umzustrukturieren.
Und konsequent so Sachen zu machen wie Container-Components und die Non-Container-Components, die halt wirklich nur so ihre Props als Input haben und dann Zeug machen.
Also, ich war halt dazu gezwungen, es so zu machen, wie ich es sowieso hätte machen sollen.
Aber vorher erlaubte mir das Paradigma, wie ich's eingesetzt habe, nehmen und dann, naja, geht schon, passt schon, schreibe ich später um, habe ich nie getan.
Und man kommt halt nicht umhin, wenn du was Neues einsetzt, kommst du, kriegst du halt deinen Kopf nicht leer und du kriegst die ganzen Erfahrungen, die du vorher gesammelt hast, nicht raus.
Du hast vorher was gelernt im ersten Anlauf und dann wird es im zweiten Anlauf automatisch besser. Die Software, die das dann wirklich zu einem schlechteren Ergebnis führt, muss halt wirklich fundamental tief ins Klo greifen.
Die muss ja so viel schlechter sein, wie du besser geworden bist.

[47:42] Also ich kann deine Aussage da zu 100% nachvollziehen und unterstützen und kann da wieder mal mein aktuelles Lieblingsartikel, was Softwareentwicklung angeht, ins Boot holen und zwar Peter Nau, Programming as Theory Building.
Ich hab in Stefan schon sehr zugetextet davon, mit der Theorie, das zu programmieren, jetzt das Endziel des Programmierens ist nicht, oder Endziel schon, aber der Aktivität, ist nicht Programmtext zu erzeugen, sondern eine Theorie darüber zu erlauern, was man programmiert.
Und natürlich, wenn man das nur einmal machen muss, dann wird man diese Theorie verfeinern.
Und was das Werkzeug dazu ist, ist wahrscheinlich gar nicht so relevant, Sondern einfach mehr, dass man das Problem durchgedacht hat, also man hat die Fehler schon einmal gemacht und zum zweiten Mal wird es natürlich dann besser.
Aber Bernhard, wenn jetzt Programmieren das Werkzeug fürs Theoriebuilding ist, wenn sozusagen ich durch diesen Akt des Selbstcodeschreibens erst lerne, was ich überhaupt brauche, wie schaffst du es denn dann, dass die KI uns alle ersetzt?

[48:52] Das ist eine Frage, die mir sehr gut gefällt, weil eigentlich habe ich gesagt, ich mag mich nicht sehr viel mit AI und KI beschäftigen, aber das ist genau die richtige Frage, die mir beantwortet, warum ich das nicht mag, weil die Antwort darauf ist, ja warum, also oder wie.
Also das ist ein falscher Versprecher. Meine Frage ist, warum.
Die richtige Frage ist, wie ...
Also, ich möcht da gar nicht, weil mir macht's ja Spaß.
Naja, zum einen macht's Spaß, zum anderen ist es teilweise notwendig.
Klar, gibt halt Aufgaben, die wegautomatisiert gehören, wie Boilerplate hier, Komponenten da.
Man kann drüber streiten, ob Boilerplate nicht auf anderer Ebene repariert werden kann, indem man ein ordentliches Framework verwendet.
Ich hab letztens mir so gedacht, wie soll das mit dem mich-Ersetzen durch irgendwie so ein Prompt-Ding funktionieren, wenn ich das selber dreimal neu schreiben muss, um überhaupt zu verstehen, wie ein Weg in die richtige Richtung überhaupt aussehen könnte.
Und jetzt kann man sagen, okay, das ist ein kleiner Teil vom ganzen Programmieren, die meisten Leute rümpeln einfach React-Komponenten raus.
Ja, wunderbar. Die kann man aber auch auf andere Weise ersetzen, indem man sich eine UI-Library klickt oder sonst irgendwie was.
Das wird halt wieder alles, ist mein Gefühl, sehr viel heißer gegessen, als es gekocht wird.

[50:11] Würde ich zu 100 Prozent unterschreiben. Also ich glaube, da ist nicht viel hinzuzufügen, weil gerade wenn man sich die momentanen Ansätze anschaut bei KI auf Probleme, weil Intelligenz und Knowledge oder Intelligenz und Wissen ist ein großer Unterschied und momentan sind das eher so LLMs, das sind Wissenssysteme, Und dann fällt genau dieser Schritt der Intelligenz, eine Theorie zu bauen, die man weiterentwickeln kann.

[50:40] Ja, also, korrigiere mich, wenn ich falsch liege, aber ich denke eben sehr viel Statistik, und das ist irgendwie nützlich, aber Wissen und Theorie, also, was ich jetzt tendenziell eher so in den Bereich von Intelligenz reinräumen würde, ist da halt eben nicht so richtig drin. Also ...
Ich glaub, du habt hier nichts korrigiert. Es kann halt eben standardisierte Aufgaben, wirklich so Dinge, die ohnehin automatisierbar gut sind, ersetzen.
Das ist wie so ein Industrieroboter, wie so ein 3D-Drucker, nur halt eben für ...
Die Atome, aus denen wir Wissen zusammensetzen, also so Text und Code und Zeug.
Aber halt auch nicht irgendwie mehr so SkyNet, bin ich immer noch nicht ganz überzeugt von.

[51:24] Mhm. Ja, ich seh das auch so. Äh ... kurze Dank.
Kurze Dank ist das so. Auch da sehe ich halt wieder bei Leuten, die halt so sagen, also ich bin jetzt kein Psychologe, ich bin mit einer Psychologin zusammen.
Bernhard, korrigiere mich, wenn ich Blödsinn rede, bevor ich mich hier zu Hause korrigieren lassen muss.
Aber auch das ist doch so eine Sache, wo man relativ schwer aus seinem Kopf rauskommt.
Ich lasse mir da jetzt irgendwelchen Code generieren und habe dann so den Eindruck, das ist genau das, was ich auch geschrieben hätte.
Aber das weiß ich doch gar nicht, wenn ich es gesehen habe, bevor ich es geschrieben habe.
Ja ohnehin mit so Mechanismen wie Confirmation Bias und ähnlichem Zeug hingeht und das Gesehene erst mal interpretiert.

[52:11] Ja, wiederum 100-prozentige Unterschrift, also es ist sehr viel einfacher zu sagen, ja natürlich hätte ich auch so geschrieben, wie es so zu schreiben.
Exakt, genau, das war, was ich eigentlich sagen wollte. Und ich finde den Aspekt, den du gerade anspruchst, total wichtig, von davor, dass es auch andere Möglichkeiten gibt, diesen Boilerplate-Code zu reduzieren, weil wenn wir uns den jetzt generieren lassen, dann müssen wir trotzdem wahrscheinlich warten.
Er existiert auf jeden Fall.
Und wenn man aber richtige Abstraktionsebenen findet, dann sind nämlich die auch nicht ab Wahrscheinlichkeit basierend.
Ob das jetzt andere UI Komponenten oder Frameworks oder Libraries und so sind, spielt dann nicht so viel Rolle.
Es ist nicht ein Komponent oder ein Aspekt unserer Software, die auch auf Probabilistik erstellt wurde.
Was mir sehr viel Ruhe gibt. Mhm.

[53:18] Boah. Gut, es kommt drauf an, wer das erstellt hat. Da gibt's ja ...
Okay, ja. Danke fürs Nehmen der Ruhe. Hahaha! Hahaha!
Naja, nee, aber da sind wir wieder bei der schwarzen Magie und den regulären Ausdrücken auf den Angular JS Funktionssignaturen.
Es führt halt keinen Weg dran vorbei, zu wissen, was das richtige Werkzeug für den jeweiligen Job ist.
Das ist sicherlich hilfreich, aber auch das wird am Ende sicherlich nicht maßgeblich sein für die Frage, wird das Projekt jetzt irgendwie ein großer Erfolg oder nicht, und ob es dann jetzt Signals sind oder nicht, und ob das jetzt irgendwie GitHub Copilot ist oder nicht, ob man jetzt eine UI Library verwendet oder nicht.
Das wird es am Ende wahrscheinlich als einzelne Faktoren echt nicht rausreißen.

[54:04] Das ist der Grund, warum ich manchmal so ein bisschen so, ich mache Hacker-News auf oder das jeweilige Twitter-Äquivalent du jour und dann gucke ich da so rein und alle irgendwie so, boah, hier das neue heiße Ding und ich so, also erstens habe ich das schon mal gesehen und das ist gar nicht so neu und zum Zweiten, am Ende ist es genau nicht so relevant, wie ihr das jetzt mir alle verkaufen wollt, aus Gründen. Also entweder, weil ihr es selber weil ihr es selber glaubt, oder weil ihr was verkaufen wollt, oder ihr einen dollen, aufregenden Thumbnail für euer YouTube braucht, oder, oder, was ja alles.
Valide Anlässe sind, das zu machen.

[54:44] Ja. Also, ich bin mittlerweile, glaube ich, zu dem Punkt gekommen, wo ich sage, ich sitze das jetzt aus.
Ich habe jetzt vor, dass ich wieder Refactoring von meiner Webseite mache.
Ich glaube, ich werde aber einfach wirklich Eleventy weiter nutzen, weil es ein faderstatischer Seitengenerator ist und ich werde mein Frontend, falls ich irgendwas dynamisch mache, genau so machen, wie ich es jetzt gemacht habe, indem ich ganz kleine JavaScript-Komponenten schreibe, die zehn Zeilen kurz sind ohne Framework.
Und ob ich dort jetzt ein reaktives Update mache oder nicht, das weiß ich noch nicht.
Ja, also, ich meine, der große Vorteil von diesen gesamtintegrierten Single-Page-Applikationen, wenn du so ein Angular hast oder ein React.
Da gibt es halt echt eine Sache drin, wo ich jetzt nicht so sehe, wie man die herstellen kann mit HTML, statischem Seitengenerator und isolierten JavaScript-Komponenten.
Und das ist halt eben tatsächlich der Faktor statisches Type-Checking.

[55:45] Das ist halt alles so ein bisschen schwierig. Wenn du wirklich so alles in JavaScript beziehungsweise Type-Script hast und das ist alles wirklich ein großes Projekt, wo alles im Prinzip Function-Called sind, dann kann das halt eben tatsächlich maschinell gecheckt werden irgendwie easy. Ja, und was ich z.B. jetzt zuletzt gebaut habe, im so Rahmen von rum experimentieren mit Web Components, mit den Klassendecorators von ECMAScript oder so, da habe ich sowas gebaut, was so ähnlich funktioniert wie ein Provider in React, sprich es gibt irgendwo ein Eltern-Element und das weiß Bescheid, was so der Zustand ist und Kind-Elemente können darauf auf eine automatische Art und Weise subscribe, was ja nicht weiter schwierig ist, wenn du dich im DOM befindest, weil du ja einfach so gucken kannst, wer imitiert hier ein Event mit Event-Delegation und irgendwie dem Closest-Selektor-Ding, kannst du ja rausfinden, für ein gegebenes Kind-Element, das ein Event registriert, welcher Provider ist mein nächstes Eltern-Element, und da beziehe ich dann die Daten her.
So. Das ist alles total auch implizit und automatischer Datenfluss und alles total toll, top-down, super, nur, weil das halt eben implizit ist und am Ende auf die DOM-Struktur ankommt, kriegt man da keine Type-Sicherheit her, wenn man nicht in den Selektor irgendwie reinschreibt, jawohl, ich suche jetzt einen Provider von genau dem Typ mit diesen Attributen zum Beispiel.
Beispiel.

[56:57] Und das ist halt eben schon, wenn es ein bisschen komplizierter wird, echt so ein bisschen ein Minus in der Developer Experience. Du kannst halt entweder dann sagen, ich verzichte auf statisches Type-Checking und dann ist es halt eben einfach JavaScript, YOLO passt schon.
Oder man hat halt eben dann Type-Script, aber halt eben mit immer dann, wenn man so eine Komponente verlässt, der Schwarzen-Loch-Effekt, dass man halt mit irgendwelchen Datenquellen arbeiten muss, wo man halt nicht wirklich weiß, was rauskommt, und das entweder glauben muss, was man meint, was da rauskommt, oder Type-Checken muss, und das ist beides halt nicht so ganz optimal.
Im Vergleich zu React, wo jedes Ding jederzeit einen Typ hat.
Keine Ahnung, wie wir aus der Nummer wieder rauskommen sollen.
Da habe ich so, glaube ich, mit dem Stefan auf der Angular-Konferenz ein bisschen drüber geredet.
Noch nicht, wir haben über ein TypeScript-Workshop geredet.
Also, ich war, ich habe jetzt gerade vorher automatisch gesagt, ich war ein riesiger Fan von statischem Typing, bin es nach wie vor. Aber gerade auch wieder dieser Artikel von Peter Now hat mir ein bisschen aufgezeigt, statisches Typing ist ein Tool, das uns irgendwie eine Kommunikation ermöglicht.
In dem Fall eine Kommunikation mit dem Compiler und im Idealfall auch eine Kommunikation mit anderen Personen im Team. Das erste ist sehr nett, das zweite ist notwendig und da gibt es Möglichkeiten natürlich mit Types oder mit anderen, es ist aber auch ein Tool zur Kommunikation und...

[58:25] Jetzt weiß ich auch selber nicht mehr, wie ich da rauskomme.
Naja, aber das würde ja sozusagen, wenn wir deiner Theorie folgen, würde das ja implizieren, dass es alternative Möglichkeiten gibt, diese Kommunikation herzustellen und damit den Effekt zu erzielen, den man auch über YouTube-Annotationen herstellt.
Stand-Ups. Ja, genau. Ja. Pair-Programming. Stand-Ups. PRs.
Aber das ist ein wichtiger Punkt. Also es geht ja wirklich um die Vermittlung von Wissen von Wissen oder um die Konservierung von Wissen. Und da gibt es andere Möglichkeiten.
Typechecking ist halt tatsächlich ein sehr eleganter und direkter Weg. Das heißt, da kommst du halt dann oft nicht vorbei. Und vor allem ein definierter Weg. Ich glaube, das ist auch nicht so unwichtig bei dem Ding. Und ein überprüfbarer Weg. Du kannst ja sozusagen dir dein Typuniversum aufbauen und auf den Knopf drücken und dann kannst du zumindest mal gucken, ob so die Gesamtheit deiner Annahmen, die explizit aufgeschrieben sind.

[59:22] Zutreffen oder nicht.
Und das ist ja so für mich auch, als ich hier Solo-Entwickler.
Also ich kann mit niemandem außer meinem Kaktus im Büro ein Stand-up machen.
Und das ist damit der Distributor ein bisschen schwieriger, wenn da nicht so viel zurückkommt.
Also für mich ist das mehr als das, so ein Kommunikationsmittel.
Für mich ist das wirklich so das Ding, das mir halt wirklich relativ deutlich erlaubt, wenn ich irgendwie einen definierten Zustand habe, relativ brutales Refactoring zu machen, wo die ganze Codebase über Tage einfach in einem komplett defekten Zustand ist, aber wo ich halt eben sagen kann, es gibt halt hier so ein lasagna-artiges Projektstruktur und da nehme ich jetzt so eine Schicht außer Mitte raus und die wird jetzt einfach mal neu gemacht und sobald halt eben an der Schicht drüber und an der Schicht drunter niemand mehr motzt, weiß ich, dass, wenn dann die Schicht in sich einigermaßen funktioniert, das dann zumindest sozusagen das Gesamtkunstwerk wird und ich halt wirklich nur die Schicht austausche und die dazugehörigen Unit-Tests, aber das Ganze ist weiterhin in sich konsistent.
Das ist eine schöne Beschreibung für eine Lasagne-Architektur.
Voll gut, also ich glaube jetzt wird es jeder verstanden haben.

[1:00:22] Jaja, das ist ja tatsächlich auch irgendwie so ein Ding, was ja irgendwie nicht en vogue ist, ne?
Model-View-Controller von früher.
Das ist heute alles Komponenten und ein hierarchischer Komponententree. Ja, super.
Aber man kann halt nicht einfach mal sagen, ich mach jetzt hier mal einen größeren Umbau und reiße jetzt mal eine ganze Etage raus und baue das neu.
Also wie das aus Frontend zu übertragen ist, habe ich keine Ahnung.
Aber wenn ich halt einfach so eine Library schreibe, dann baue ich die definitiv lasagne-mäßig auf, damit ich halt sagen kann, brutale Refactorings innerhalb eben einer Etage sind halt eben möglich.
Und dazu brauche ich dann schon den TypeScript-Support.
Ja, das stimmt.

[1:00:54] Macht auf jeden Fall einiges einfacher. Ja.
Apropos Kommunikation. Ich denke, das ist jetzt ein sehr guter Punkt, nachdem wir schon ganz woanders sind, als wie ursprünglich, wo wir ursprünglich gestartet haben.
Verlagern wir die Kommunikation in unsere neuen Web-Menschen.
Also, wir haben jetzt eine neue Webseite, sehr kurzen.
Und ihr könnt uns quasi, wenn ihr die URL habt, könnt ihr uns auf Mastodon erwähnen oder auf Twitter oder jedem anderen webmenschenfähigen Social Network und eure Kommentare, eure Tweets etc.
Scheinen dann direkt bei uns in den Episoden auf, beziehungsweise engagiert euch in Gesprächen mit uns.
Also wenn ihr denkt, hey, die drei haben jetzt sehr stark philosophiert über unterschiedliche Frameworks, haben ein bisschen technischen Background gegeben, ihr wisst es alles besser und ihr habt tatsächlich Use Cases, die sehr, sehr stark für Signal sprechen, außer dem Rewrite, dann bitte meldet euch bei atworkingcraft.podcast.social oder auf Twitter oder in unserem Community-Draft. Wir haben überall Wege und Möglichkeiten, dass ihr mit uns in Kontakt tretet und wir würden uns freuen, wenn wir dort vielleicht ein Follow-Up drauf machen.

[1:02:06] Ist das jetzt gut genug gesegwayed? Ich mach das zum ersten Mal, aber der Peter muss halt zwei Minuten weg.
Das ist die beste Abmoderation, die ich je aus einem Mund gehört habe, der nicht zu Hans gehört.
Okay, dann hätte ich aber gesagt, hey, danke Bernhard für das spontane Vorbeischauen, danke Peter für wieder eine ordentliche Sitzung der Diskussion der alten Männer und Softwareentwicklung.
Das werden wir auch verlinken, es gibt, der Bernhard hat uns ein Paper zur Verfügung gestellt, wie Signals damals unter einem ganz anderen Namen in Smalltalk implementiert worden sind.
Und das werde ich mir jetzt zur Gemüte führen bei meinem zweiten Kaffee.
Und genau, ich glaube, das war eine ganz falsche Sendung insofern.
Das war's. Ja, vielen Dank.
Okidoki. Viel Spaß dabei. Sagt man jetzt noch Tschüss zum Schluss?
Natürlich, Tschüssi. Ok, Tschüss. Tschüdi Nöst!

[1:03:02] Music.